1. Field of the Invention
The present invention relates to a Host Identity Protocol Method and Apparatus.
2. Description of the Related Art
When the Internet was originally devised, hosts were fixed in location and there was implicit trust between users despite the lack of real security or host identification protocols, and this situation continued even upon wider uptake and use of the technology. There was little need to consider techniques for dealing with host mobility since computers were relatively bulky and immobile.
Taking into account the above mobility management and security issues, the Mobile IP standard (C. Perkins, “IP Mobility Support for IPv4”, RFC 3220, IETF, 2002) and the Mobile IPv6 standard (D. Johnson, C. Perkins, J. Arkko, “Mobility Support in IPv6”, RFC3775, IETF, 2004) have been introduced. Together these specifications are planned to provide mobility support for the next generation Internet. Security work is developing in the form of IPsec, and related activities, such as various key exchange protocols, with the aim being to provide security in the IP layer. However, experience has shown that it is fairly hard to reach combined security and mobility using the current standards.
An IP address describes a topological location of a node in the network. The IP address is used to route the packet from the source node to the destination. At the same time the IP address is also used to identify the node, providing two different functions in one entity. This is akin to a person responding with their home address when asked who they are. When mobility is also considered, the situation becomes even more complicated: since IP addresses act as host identifiers in this scheme, they must not be changed; however, since IP addresses also describe topological locations, they must necessarily change when a host changes its location in the network. Clearly, it is impossible to achieve both stability and dynamic changes at the same time.
One solution to the problem is to separate the identification and location functions from each other, and this is the approach taken in the Host Identity Protocol (HIP) proposal (R. Moskowitz, P. Nikander, P. Jokela, “Host Identity Protocol”, Internet Draft, work in progress, draft-ietf-hip-base-02, IETF, 2005). HIP separates the location and identity roles of IP addresses by introducing a new name-space, the Host Identity (HI). In HIP, the Host Identity is basically a public cryptographic key of a public-private key-pair, and is generated from and linked to the private key. The public key identifies the party that holds the only copy of the private key. A host possessing the private key of the key-pair can directly prove that it “owns” the public key that is used to identify it in the network. The separation also provides a means to handle mobility and multi-homing in a secure way.
HIP is discussed in more detail below, but is not the only proposal based around the idea of location and identity separation. FARA (D. Clark, R. Braden, A. Falk, V. Pingali, “FARA: Reorganizing the Addressing Architecture”, ACM SIGCOMM 2003 Workshops, Aug. 25 & 27, 2003) is a generalized model of ideas that provides a framework from which the actual architecture can be derived. FARA could make use of the HIP when the node identifications are verified, and consequently HIP could be a part of a particular FARA instantiation. The PeerNet proposal (J. Eriksson, M. Faloutsos, S. Krishnamurthy, “PeerNet: Pushing Peer-to-Peer Down the Stack”, IPTPS '03, Feb. 20-21, 2003) also discusses the location and identity separation. The Internet Indirection Infrastructure, I3 (I. Stoica, et. al., “Internet Indirection Infrastructure”, ACM SIGCOMM '02, Aug. 19-23, 2002) also defines a separation between the identity and routing information.
The Host Identity Protocol introduces a separation between the location and identity information at the IP layer. In addition to the separation, a protocol is defined to negotiate security associations (SAs) between HIP-enabled nodes.
With HIP, each host has one or more identities, which can be long-term or short-term, that can be used to identify it in the network. With HIP, an identifier is the public key of a public-private key pair. When the host possesses the private key, it can prove that it actually “owns” this identity that the public key represents; this is akin to showing an ID-card.
The HIP Host Identity (HI), being a public key, can be quite long and is therefore not practical in all situations. In HIP, the HI is represented with a 128-bit long Host Identity Tag (HIT) that is generated from the HI by hashing it; there is accordingly a slight collision risk whereby two HIs are hashed to the same HIT. Thus, the HIT identifies a HI. Since the HIT is 128 bits long, it can be used for IPv6 applications directly as it is exactly the same length as IPv6 addresses.
Another representation of the Host Identities is the Local Scope Identifier (LSI), which is a 32-bit representation for the Host Identity. The purpose of the LSI is to facilitate using Host Identities in existing protocols and APIs. For example, since the LSI is the same length as an IPv4 address, it can be used for IPv4 applications directly. Although much of the remainder of this description will be based around the use of the longer HIT, it will be appreciated that the same or similar considerations apply to the alternative LSI representation.
When HIP is used, the upper layers, including the applications, no longer see the IP address. Instead, they see the HIT as the “address” of the destination host. The location information is hidden at a new layer, to be described below. The IP addresses no longer identify the nodes; they are only used for routing the packets in the network. Applications are not typically interested in location information but do need to know the identity of their peers. The identity is represented by the HIT. This means that the IP address only has importance on lower layers where routing is concerned. The HITs, which the applications use, must be mapped to the corresponding IP addresses before any packets leave the host. This is achieved in a new Host Identity Layer as described below.
FIG. 1 of the accompanying drawings illustrates the various layers in HIP, comprising the standard transport layer 4, network layer 8 and link layer 10, with an application or process 2 communicating with the transport layer 4 below it. With HIP, a new Host Identity Layer 6 is disposed between the transport layer 4 and the network layer 8.
Locally, each HI and its associated HIT are mapped to the IP addresses of the node. When packets are leaving the host, the correct route is chosen (by whatever means) and corresponding IP addresses are put into the packet as the source and destination addresses. Each packet arriving from the upper layer contains the HIT of the peer as the destination address. The mapping between the HIT and the location information can be found at the HI layer 6. Hence, the destination address is converted to the mapped IP address, and the source HIT is converted to source IP address.
HIP defines a base message exchange containing four messages, a four-way handshake, and this is used to create a security association (SA) between HIP-enabled hosts. During the message exchange, the Diffie-Hellman procedure is used to create a session key and to establish a pair of IPsec Encapsulating Security Payload (ESP) Security Associations (SAs) between the nodes.
FIG. 2 of the accompanying drawings illustrates the operation of the four-way handshake. The negotiating parties are referred to as the Initiator, starting the connection, and the Responder. The Initiator begins the negotiation by sending an I1 packet that contains the HITs of the nodes participating in the negotiation. The destination HIT may also be zeroed, if the Responder's HIT is not known by the Initiator.
When the Responder gets the I1 packet, it sends back an R1 packet that contains a puzzle to be solved by the Initiator. The protocol is designed so that the Initiator must do most of the calculation during the puzzle solving. This gives some protection against Denial of Service (DoS) attacks. The R1 packet also contains the HITs of the nodes participating in the negotiation. In addition, the R1 packet initiates the Diffie-Hellman procedure, containing the Host Identity public key PKR of the Responder together with Diffie-Helhman parameters including the public Diffie-Hellman key DHR of the Responder.
Once the R1 packet is received, the Initiator solves the puzzle and sends a response in an I2 packet including the solution together with an IPsec SPI value and its Host Identity public key PKI, encrypted using a session key constructed with the Responder's public Diffie-Helhnan key DHR just received, to the Responder (although encryption of the Host Identity public key PKI is becoming optional in the standard HIP protocol). The I2 packet also contains the HITs of the nodes participating in the negotiation, and the Diffie-Hellman key DHI of the Initiator. The Responder verifies that the puzzle has been solved, authenticates that the sender of the message is the Initiator by verifying that the message signature has been created by the private key corresponding to the Initiator's Host Identity public key PKI, and creates the IPsec ESP SAs. The final R2 message contains the SPI value of the Responder, and the HITs of the nodes participating in the negotiation. It is appreciated that creating the IPsec ESP SAs is becoming optional in the standard HIP base exchange.
In addition to the I1, R1, I2, and R2 packets, the HIP specification defines other packets, including the UPDATE packet. While there is an active HIP association between two communicating HIP-enabled hosts, the UPDATE packet can be used to update the shared state; for example, the UPDATE packet is used to update ESP Security Associations. There are extensions to the HIP base specification, for example, the HIP Mobility and Multi-homing protocol (P. Nikander, J. Arkko, P. Jokela, “End-Host Mobility and Multihoming with Host Identity Protocol”, Internet Draft, work in progress, draft-ietf-hip-mm-01, IETF, 2005), that use the UPDATE packets for various purposes. It is noted that a HIP host ignores and drops UPDATE packets if it does not have any active HIP association with the sender of the UPDATE packet.
The SAs between the hosts are bound to the Host Identities, represented by the HITs. However, the data packets travelling in the network do not contain the actual HI information, but the arriving packet is identified and mapped to the correct SA using the Security Parameter Index (SPI) value in the IPsec header. FIG. 3 of the accompanying drawings shows the logical and actual packet structures when it travels in the network.
From the above it is clear that changing the location information in the packet does not create any problems for the IPsec processing. The packet is still correctly identified using the SPI. If, for some reason, the packet is routed to a wrong destination, the receiver is not able to open the packet as it does not have the correct key.
When an outgoing packet arrives at the HI layer from the above layer, the destination HIT is verified from the IPsec SADB. If an SA matching to the destination HIT is found, the packet is encrypted using the session key associated with the SA.
The HIT cannot be used to route the packet. Thus, the destination (and source) addresses must be changed to match the IP addresses of the nodes. These mappings are stored, as mentioned earlier, in the HI layer. After the addresses have been changed, the packet can be sent to the network where it is routed to the destination using the IP address information.
At the receiving host, the SPI value is used to find the correct SA form the IPsec SADB. If an entry is found, the IP addresses can be changed to corresponding HITs and the packet can be decrypted using the session key.
With HIP, the separation between the location and identity information makes it clear that the packet identification and routing can be cleanly separated from each other. The host receiving a packet identifies the sender by first getting the correct key and then decrypting the packet. Thus, the IP addresses that are in the packet are irrelevant.
Other technical considerations arise when implementing HIP in third generation (3G) mobile telecommunications networks where not all of the User Equipments (UEs) in the 3G environment are HIP enabled. In this context, the Universal Mobile Telecommunications System (UMTS) is the 3G successor to the Global System for Mobile Communications (GSM). The most important evolutionary step of GSM towards UMTS is the General Packet Radio Service (GPRS). GPRS introduces packet switching into the GSM core network and allows direct access to packet data networks (PDNs). This enables high-data rate packet switched transmission well beyond the 64 kbps limit of ISDN through the GSM core network, which is a necessity for UMTS data transmission rates of up to 2 Mbps. GPRS is a prerequisite for the UMTS introduction. Similar principles are equally applicable to UMTS as they are to GPRS. GPRS has been designed as an extension to the existing GSM network infrastructure, with the aim of providing a connectionless packet data service. GPRS introduces a number of new functional elements over GSM that support the end-to-end transport of IP-based packet data.
As mentioned above, the full base exchange protocol is a four-message two-round-trip protocol. The Hi3 proposal (Internet Draft, work in progress, draft-nikander-hiprg-hi3-00.txt] makes a proposal to reduce one round trip at the Responder end by storing the pre-computed R1 messages into a middle box and letting the middle box reply to I1 messages directly, thereby reducing the messages that the Responder sees to I2 and R2, i.e. two messages and one round trip. However, this solution does not change the situation at the Initiator end.
Considering a wireless HIP base exchange Initiator, the two round trips in the full HIP base exchange protocol can create a performance problem. Requiring the Initiator to wait for two round trips before it can communicate with the Responder forms a potential performance bottleneck. It would be desirable to reduce the number of required messages and thereby reduce the session setup latency.